Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/ucp/ucp-minutes-90july.txt

Text File | 1993-02-17 | 7.4 KB | 217 lines

CURRENT_MEETING_REPORT_


Reported by Dan Long/BBN

UCP Minutes

Agenda


   o Introduction to UCP Working Group:

      -  What is it?  What's been done so far?
      -  Discussion of Matt Mathis' National Trouble Ticket Tracking
         writeup.
      -  Discussion of some operational issues by MERIT.
      -  What's Next?


Dan Long (Chair) presented a brief history of the UCP Working Group:


   o FSU IETF: Initial discussion

      -  Structural proposals presented
      -  Refine goals/scope
      -  Writeups by Craig, Elise, & Martyne

   o PSC IETF: Definition of terms:
      -  NSC (Network Service Center)
      -  P1 (user<->NSC communication protocol)
      -  P2 (NSC<->NSC communication protocol)
      -  Writeup by Matt


Matt Mathis (PSC) reviewed his description of a National Trouble Ticket
Tracking system.  A lively discussion ensued about various aspects of
the proposal including:


   o How do you define ``closure with the user'' (as in ``a ticket is a
     contract to obtain closure with a user'')?

      -  What do you do about uncooperative NOC's?
      -  What do you do when you cannot satisfy the user due to
         funding/engineering constraints?
      -  Transfer of a ticket is a mechanism for obtaining closure and
         resolving the problem.  We should acknowledge that certain
         problems can't be closed in a technical sense.  This may be
         sufficient for closure with the user.

   o What are the organizational implications of declaring a ticket to

                                   1






     be a ``contract''?
      -  Does that mean the NSC must respond to any old barage of
         (nuisance) questions?
      -  Can an organization commit to adhering to this system without
         knowing the expected demand?
   o How are NSC's ``certified'' (as in ``NSC's must be certified at
     least as far as adherence to the rules described in this
     document'')?

      -  We don't want to be (or can't be) coercive.
      -  Needs some element of informal (polite) coercion rather than
         legal coercion.  The problem is to get somebody to start owning
         the problem and a way of recording where the problem lies.
      -  Makes more sense to have the system be so useful that everyone
         will want to join and conform.
      -  Certification should only be that the NSC's adhere to the
         ticket hand-off protocols.  Details of P2 protocol need to be
         fleshed out by the person who sets up the TTC.

   o What about peer-bashing (i.e., pointing fingers, blaming,...)?

      -  It's self-regulating (...glass houses...stones...).
      -  Would a national ombudsman be reasonable?

   o What about lots of users complaining about the same problem?

      -  Have multiple user dialogs cross referenced with a single
         ``problem'' which has the other dialogs.
      -  Closure should be obtained with each user.
      -  We do want to track each caller so we know how many complaints
         there are.

   o What about privacy of ticket information?
      -  Tickets should be readable only by the owner and the ticket
         arbitrage center (TAC).
   o What do you do with the Engineering Dialog results?

      -  If the Engineering Dialog results in suggested improvements,
         how do those get handled?
      -  Does everyone who hears about the suggestions understand the
         possible implementation obstacles?


Dale Johnson (Merit) led a discussion on some aspects of this system not
covered in the document:


   o Any national Ticket Tracking system will have to be used in
     conjunction with local systems.  For large sites which have
     elaborate highly customized systems of their own, this might
     require software to automatically copy tickets between the local
     and national system.  Making the national system available for all
     networks' local tickets could simplify operations for many NOCs,

                                   2






     although this could result in an extremely expensive national
     system.  If the national system was freeware or was reasonably
     available, then NOCs could at least use the same software for both
     their local and national tickets.
   o NSC's still need the tools to do the diagnosis.  Especially
     important is contact information for different network entities.
     The NNSC Phone Book may help solve this problem.  Contact
     information should be both published and online.
   o The NJM Working Group has started discussing common data formats
     and access mechanisms for the routine (SNMP and other) data that
     NOCs collect.  Access to this kind of data from other networks
     could become very useful when a NOC tries to debug a complex
     problem outside of its own jurisdiction, or when another entity
     wants to aggregate or contrast data from different NOCs.  NJM will
     continue with this project, but noted that this might also be
     interesting to the UCP group because it is a form of inter-NOC
     communication.
   o How can we alert network users about outages, both planned and
     unplanned?  How about an X.500-based (or DNS-based) posting system
     that people (and network utilities?)  can query to determine the
     operational status of various network components?  There was a fair
     amount of discussion about a low-tech short-term solution involving
     a standard format for problem reports posted to the NSR mailing
     list.  The thought was that these standard reports could then be
     automatically collected for occasional perusal/reference by NSC
     staff.


Action Items


   o Matt - will redraft with the suggested changes from the discussion:

      -  No compulsion; be neutral
      -  Privacy; tickets readable only by owner and TAC
      -  TAC will mention the ombudsman role
      -  Omit details of ticket format (for now)
      -  Need requirements for TTC
      -  It's ok for 1 ticket to have multiple user dialogs

   o Dan/Craig - will clean up draft & submit into the FYI RFC pipeline

      -  Check FYI RFC standards to be sure that the ``2 voice'' format
         is acceptable
      -  Provide copy of draft to FARNET's September meeting


Timetable Through 1990



August              Matt will present revised draft; UCP group to
                    comment

                                   3






September           Dan/Craig will incorporate comments, and prepare
                    draft for presentation to FARNET and submission to
                    FYI RFC pipeline
October/November    Collect comments and refine proposal.
December            At IETF meeting, discuss deployment/future plans



Attendees


Stephen Adams            decwrl::``adams@zeppo''
Eric Carroll             [e-mail]
Carol Farnham            [e-mail]
Dale Finkelson           [e-mail]
Vince Fuller             [e-mail]
Steven Hubert            [e-mail]
Dale Johnson             [e-mail]
Ken Jones                uunet!konkord!ksj
Dan Long                 [e-mail]
Matt Mathis              [e-mail]
Berlin Moore             [e-mail]
Donald Morris            [e-mail]
Craig Partridge          [e-mail]
Dana Sitzler             [e-mail]
Allen Sturtevant         [e-mail]
Carol Ward               [e-mail]
Robert Woodburn          [e-mail]



                                   4